1. Field of Invention
The present invention relates generally to the field of software applications used on an information network (such as a cable television network), and specifically to the accessibility and control of on-demand and related services at certain electronic devices such as, e.g., set-top boxes used in the network during operation of the software.
2. Description of Related Technology
Software applications are well known in the prior art. Such applications may run on literally any type of electronic device, and may be distributed across two or more locations or devices connected by a network. Often, a so-called “client/server” architecture is employed, where one or more portions of applications disposed on client or consumer premises devices (e.g., PCs, PDAs, digital set-top boxes {DSTBs}, hand-held computers, etc.) are operatively coupled and in communication with other (server) portions of the application. Such is the case in the typical hybrid fiber coax (HFC) or satellite content network, wherein consumer premises equipment or CPE (e.g., DSTBs or satellite receivers) utilize the aforementioned “client” portions of applications to communicate with their parent server portions in order to provide downstream and upstream communications and data/content transfer.
Digital TV (DTV) is an emerging technology which utilizes digitized and compressed data formats (e.g., MPEG) for content transmission, as compared to earlier analog “uncompressed” approaches (e.g., NTSC). The DTV content may be distributed across any number of different types of bearer media or networks with sufficient bandwidth, including HFC, satellite, wireless, or terrestrial. DTV standards such as the OpenCable Application Platform middleware specification (e.g., Version 1.0, and incipient Version 2.0) require that applications be downloaded to CPE from the bearer or broadcast network in real-time. As is well known, the OCAP specification is a middleware software layer specification intended to enable the developers of interactive television services and applications to design such products so that they will run successfully on any cable television system in North America, independent of set-top or television receiver hardware or operating system software choices. OCAP enables manufacturers and retail distributors of set-tops, television receivers or other devices to build and sell devices to consumers that support all services delivered by cable operators.
Multimedia Home Platform (MHP) defines a generic interface between interactive digital applications and the terminals on which those applications execute. This interface decouples different provider's applications from the specific hardware and software details of different MHP terminal implementations. It enables digital content providers to address all types of terminals ranging from low-end to high-end set top boxes, integrated digital TV sets and multimedia PCs. The MHP extends the existing DVB open standards for broadcast and interactive services in all transmission networks including satellite, cable, terrestrial and microwave systems.
Multimedia Home Platform (MHP) Specification 1.0.X contains detailed information on the enhanced broadcasting and interactive profiles, as well as various MHP content formats including PNG, JPEG, MPEG-2 Video/Audio, subtitles and resident and downloadable fonts. MHP 1.0 further provides mandatory transport protocols including DSM-CC object carousel (broadcast) and IP (return channel), DVB-J application model and signaling, hooks for HTML content formats (DVB-HTML application model and signaling), a graphics reference model, and Annexes with DSM-CC object carousel profile, text presentation, minimum platform capabilities, and various APIs. The MHP 1.0 specification provides a set of features and functions required for the enhanced broadcasting and interactive broadcasting profiles. The enhanced broadcasting profile is intended for broadcast (one way) services, while the interactive broadcasting profile supports in addition interactive services and allows MHPs to use the Internet. New profiles will be added later based on the continuing work of the DVB project.
Multimedia Home Platform (MHP) Specification 1.1.X contains further detailing of Interactive and Internet Access Profiles, stored application support, application download via broadcast or interaction channels, DVB-J extensions to better support international applications and smart cards, specification of DVB-HTML, greater support for plug-ins, and support for bi-directional referencing between MHP content and Internet content. MHP 1.1 builds on the MHP 1.0 specification in order to better support the use of the interaction channel and to specify elements which promote interoperability with Internet content.
The Advanced Common Application Platform (ACAP) is a recently developed specification which aims to ensure interoperability between ACAP applications and different implementations of platforms supporting ACAP applications. The architecture and facilities of the ACAP Standard are intended to apply to broadcast systems and receivers for terrestrial (over-the-air) broadcast and cable TV systems. In addition, the same architecture and facilities may be applied to other transport systems (such as satellite).
ACAP is primarily based on GEM and DASE, and includes additional functionality from OCAP. GEM provides a framework for the definition of a GEM Terminal Specification. The ACAP specification builds on GEM by adding specification elements in order to offer a higher degree of interoperability among different environments based on digital TV specifications from ATSC and SCTE.
An ACAP Application is a collection of information which is processed by an application environment in order to interact with an end-user or otherwise alter the state of the application environment. ACAP Applications are classified into two categories depending upon whether the initial application content processed is of a procedural or a declarative nature. These categories of applications are referred to as procedural (ACAP-J) and declarative (ACAP-X) applications, respectively. An example of an ACAP-J application is a Java TV™ Xlet composed of compiled Java™ byte code in conjunction with other multimedia content such as graphics, video, and audio. An example of an ACAP-X application is a multimedia document composed of XHTML markup, style rules, scripts, and embedded graphics, video, and audio.
Application environments are similarly classified into two categories depending upon whether they process procedural or declarative applications. These categories are referred to as ACAP-J and ACAP-X environments, respectively. An example of an ACAP-J environment is a Java Virtual Machine (JVM) and its associated Application Programming Interface (API) implementation. An example of an ACAP-X environment is an XHTML multimedia document browser, also known as a user agent.
In the OCAP, MHP, and ACAP standards, several protocols are defined for accessing broadcast media and files. These generally specify use of the Sun Microsystems Java Media Framework APIs (hereinafter “JMF”). The JMF enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers and provides a toolkit to develop scalable, cross-platform technology. The JMF includes a set of components, including the JMF Player API.
With the JMF Player API, programmers can implement support for many audio or video formats by building upon an established media playback framework. In addition, standard implementations provide built-in support for common formats such as muLaw, Apple AIFF, and Microsoft PC WAV for audio, as well as Apple QuickTime video, Microsoft AVI video, and Motion Picture Expert Group's MPEG formats for video. Multimedia playback can also be readily integrated into applets and applications alike with only a limited amount of code.
JMF also allows use of native methods for greater speed, and hence more optimized performance on each platform. At the same time, the common Java Media Player API ensures that applets and standalone applications will run on any Java platform.
A variety of different approaches to implementing media handling and management within networked systems (including use of JMF) are disclosed in the prior art. For example, U.S. Pat. No. 6,092,107 to Eleftheriadis, et al. issued Jul. 18, 2000 and entitled “System and method for interfacing MPEG-coded audiovisual objects permitting adaptive control” discloses a system and method allowing the adaptation of a non-adaptive system for playing/browsing coded audiovisual objects, such as the parametric system of MPEG-4. The system of the invention (programmatic system) incorporates adaptive behavior on top of the parametric system. The parametric system of MPEG-4 consists of a Systems Demultiplex (Demux) overseen by digital media integration framework (DMIF), scene graph and media decoders, buffers, compositer and renderer. The Java Virtual Machine and Java Media Framework (JVM and JMF) are used to various of the aforementioned components. The invention includes a specification of an interfacing method in the form of an application programming interface (API). Hot object, directional, trick mode, transparency and other interfaces are also specified.
U.S. Pat. No. 6,181,713 to Patki, et al. issued Jan. 30, 2001 and entitled “Selectable depacketizer architecture” discloses a scheme that permits the use of a selectable depacketization module to depacketize data streams. An RTP session manager (RTPSM) is responsible for receiving RTP packets from a network and parsing/processing them. A specific depacketizer module is located at runtime depending on the coding decoding scheme (“codec”) used to compress the incoming data stream. A naming convention is followed in order for a specific depacketizer to be located. The depacketizer receives data that has already been parsed and is in a readable form. The depacketizer outputs this data using an interface designed such that it is generic across a number of codecs. The interface passes all relevant information to the decoder where the actual depacketized data stream will be decompressed. The RTPSM need not know of any codec details since the depacketizer handles all codec specific issues. A default format is described for data that is output by a depacketizer. This data is provided to a handler that is aware of this format. Pluggable depacketizer naming and searching conventions are designed according to JMF's player factory architecture, and use the same rules for integrating depacketizers into the RTPSM.
U.S. Pat. No. 6,216,152 to Wong, et al. issued Apr. 10, 2001 and entitled “Method and apparatus for providing plug in media decoders” discloses a method and apparatus for providing plug-in media decoders. Embodiments provide a “plug-in” decoder architecture that allows software decoders to be transparently downloaded, along with media data. User applications are able to support new media types as long as the corresponding plug-in decoder is available with the media data. Persistent storage requirements are decreased because the downloaded decoder is transient, existing in application memory for the duration of execution of the user application. The architecture also supports use of plug-in decoders already installed in the user computer. One embodiment is implemented with object-based class files executed in a virtual machine to form a media application. A media data type is determined from incoming media data, and used to generate a class name for a corresponding codec (coder-decoder) object. A class path vector is searched, including the source location of the incoming media data, to determine the location of the codec class file for the given class name. When the desired codec class file is located, the virtual machine's class loader loads the class file for integration into the media application. If the codec class file is located across the network at the source location of the media data, the class loader downloads the codec class file from the network. Once the class file is loaded into the virtual machine, an instance of the codec class is created within the media application to decode/decompress the media data as appropriate for the media data type.
U.S. Pat. No. 6,631,350 Celi, Jr., et al. issued Oct. 7, 2003 and entitled “Device-independent speech audio system for linking a speech driven application to specific audio input and output devices” discloses a device-independent speech audio system for linking a speech driven application to specific audio input and output devices can include a media framework for transporting digitized speech audio between speech driven applications and a plurality of audio input and output devices. The media framework can include selectable device-dependent parameters which can enable the transportation of the digitized speech to and from the plurality of audio input and output devices. The device-independent speech audio system also can include an audio abstractor configurable to provide specific ones of the selectable device-dependent parameters according to the specific audio input and output devices. Hence, the audio abstractor can provide a device-independent interface to the speech driven application for linking the speech driven application to the specific audio input and output devices.
U.S. Pat. No. 6,631,403 to Deutsch, et al. issued Oct. 7, 2003 and entitled “Architecture and application programming interfaces for Java-enabled MPEG-4 (MPEG-J) systems” discloses an MPEG-J collection of Java application programming interfaces (APIs) with which applications can be developed to interact with the platform and the content. In the context of MPEG-J, the platform is a device like a set-top box or a PC with Java packages conforming to a well-defined Java platform. The Java-based application consists of Java byte code, which may be available from a local source, like a hard disk, or it may be loaded from a remote site over a network. The MPEG-J Java byte code may be available as a separate elementary stream. The MPEG-4 system is the “Presentation engine” of MPEG-J. MPEG-J provides programmatic control through an “Application engine” which enhances the MPEG-4 browser by providing added interactive capability.
U.S. Pat. No. 6,654,722 to Aldous, et al. issued Nov. 25, 2003 and entitled “Voice over IP protocol based speech system” discloses a VoIP-enabled speech server including a JMF interface and speech application which can be configured to communicate with a VoIP telephony gateway server over a VoIP communications path. In operation, the speech application can receive VoIP-compliant packets from the VoIP telephony gateway server over the VoIP communications path. Subsequently, digitized audio data can be reconstructed from the VoIP-compliant packets, and the digitized audio data can be speech-to-text converted. Additionally, text can be synthesized into digitized audio data and the digitized audio data can be encapsulated in VoIP-compliant packets which can be transmitted over the VoIP communications path to the telephony gateway server. The JMF media interface is used to establish a data path for transporting the digital audio data between the speech application and the voice call connection.
U.S. Patent Application Publication 20020073244 to Davies, et al. published Jun. 13, 2002 entitled “Method and an apparatus for the integration of IP devices into a HAVi network” discloses a method and apparatus for integrating IP devices into a HAVi network. An Internet Protocol (IP) and HAVi compliant device acts as a controller in the HAVi network and communicates with at least one HAVi compliant device using HAVi application programming interfaces (APIs). A server on the controller communicates with at least one IP device having a proxy and an IP and HAVi API. The server includes at least one IP device control module (IP device DCM) corresponding to the IP device. The IP device providing API support to translate and relay calls between the proxy and the server so that at least one HAVi compliant device can communicate with the IP device. In one embodiment, JMF and C++ graphic libraries are used in conjunction with a streaming module to get the stream data and display the stream data.
U.S. Patent Application Publication 20030037331 to Lee published Feb. 20, 2003 and entitled “System and Method for Highly Scalable Video on Demand” discloses a system and method for providing video on demand including pre-scheduled multicasts of videos as well as dynamically initiated transmissions of the front portion of videos. Users may first receive a dynamically initiated front portion of a video and then be merged into a pre-scheduled multicast. The dynamically initiated transmission is also a multicast. Multiple admission controllers and a single server coordinate the dynamically initiated transmissions for any one video. Preferably, interactive controls are supported without requiring extra server-side resources, and latency is automatically equalized between users admitted via the pre-scheduled and the dynamically initiated transmissions. A user receiving a video via a pre-scheduled multicast does not need to change channels to finish receiving the video transmitted. Client applications implemented using the Java programming language and the Java Media Framework (JMF) are also disclosed.
In the aforementioned OCAP, MHP and ACAP standards, several protocols are defined for accessing broadcast media and files. These protocols are indicated in string form, and are encapsulated in the standards using a Locator object that contains the protocol and any other terms necessary to identify a service and its elements. In each standard, the protocols must be supported by JMF. The JMF MediaHandler understands the content format of the media associated with a protocol string, and the JMF DataSource understands the actual messaging and packet protocol associated with a protocol string.
OCAP, for example, allows an application to extend the given protocols in an application-specific fashion. This is performed by calling the JMF PackageManager “set-prefix” methods. Setting the prefixes to provide an extended protocol is defined by JMF, which allows changes made by the “set” methods to be made persistent by providing commit-prefix methods.
However, neither OCAP nor the other prior art approaches described above allow an application to call these commit-prefix methods and make them persistent. This means when more than one application needs to add the same protocol, each application must perform a redundant set prefix process, or communicate with an application that has set the prefixes using Inter-Xlet communications (IXC), as defined by MHP 1.0.2 and complied with in OCAP 1.0.
Accordingly, there is a need for improved apparatus and methods for providing network-specific services in a standards compliant fashion. Such improved apparatus and methods would ideally utilize existing media handling infrastructure (e.g., the JMF APIs or comparable) to enables a network specific protocol for handling various services within the device, such as video on-demand (VOD). Such improved apparatus and methods would also ideally permit an MSO or other entity to add the network-specific protocols to the device such that comparable services (e.g., VOD) could operate on CPE within a number of heterogeneous networks.